fix(files_sharing): don't abort share:list when orphaned shares exist#62060
Open
Fantu wants to merge 1 commit into
Open
fix(files_sharing): don't abort share:list when orphaned shares exist#62060Fantu wants to merge 1 commit into
Fantu wants to merge 1 commit into
Conversation
`occ share:list` resolved the source node of every share without handling NotFoundException, so a single orphaned share (e.g. the source file was deleted from disk externally, or is pending removal by DeleteOrphanedSharesJob) aborted the whole command with "Node for share not found" and produced no output at all. Catch the exception in both places that resolve the share node: orphaned shares are now listed with a null source-path, and the --parent filter skips them instead of crashing. Add unit tests for the command (previously untested), covering listing with an orphaned share present and the --parent filter with and without --recursive. Closes nextcloud#61949 Assisted-by: ClaudeCode:claude-fable-5 Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Fantu
requested review from
icewind1991,
leftybournes,
provokateurin and
salmart-dev
and removed request for
a team
Author
|
I have now also tested the fix on a small production server running Nextcloud 32.0.11 (patch applied manually to @icewind1991 thank you for adding the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
For several years I have been administering a server where 50–60 people work mainly with Nextcloud and Onlyoffice, and over the years they have created thousands of user shares.
When someone asked me to restore files from backup, in the cases involving shares between users they often could not tell me the exact origin of the shared file, and in two cases I wasted a lot of time because of that.
Since occ had no
share:listcommand at the time, I had written an external script that generated a similar list every day, so that during a restore I could quickly find the origin of a share by looking at that list in a backup from a day when the share still existed.Nextcloud 32 finally added
share:listto occ, but unfortunately on that server (and I suppose in many other cases) it was unusable: some orphaned shares are always present, and a single one is enough to make the whole command abort.I considered working around it by always deleting the orphaned shares first, but I don't want to lose the few cases where a restore can actually repair a share, nor risk needlessly removing shares because of temporary problems with the SMB file server or something else.
So I made this change so that the command also works when orphaned shares exist.
Note that orphaned shares are not skipped but included in the list, even though the most important piece of information (the source path) is missing and shown as empty/null. For cases like mine this still has some value: from the orphaned entries you can immediately tell whether a share with the exact name (or a similar one) mentioned by the user actually existed, and who it was shared with. This is already a small improvement over my old external script, which excluded orphaned shares, so I had to dig through several backups just to confirm that the share had existed at all and what it was called. I think keeping the orphaned entries visible where possible can be useful to others as well.
I also added unit tests to catch possible regressions; this command previously had no tests at all.
TODO
Checklist
3. to review, feature component)stable32)AI (if applicable)